Una aplicación móvil para pedir taxi

1. Definir los requisitos de negocio (3 puntos, 1 punto cada apartado)

1.1 Enunciar la visión del producto

Para aquellas personas que utilicen habitualmente el transporte público, MyTaxi ofrece una opción sencilla para la realización de reservas a través de la aplicación móvil. A diferencia de otras aplicaciones existentes, MyTaxi permite a sus usuarios reservar el taxi que necesiten (ECO, accesible, XL...), controlar cuándo llega su taxi y pagar el trayecto fácilmente a través de la aplicación.

1.2 Enunciar dos objetivos de negocio, con sus correspondientes métricas de éxito

Objetivos de negocio

• O1. Alcanzar una base de 10000 usuarios activos en el primer semestre desde el lanzamiento.

• O2. Conseguir al menos 200 usuarios premium al cabo de un semestre desde el lanzamiento.

Métricas de éxito

• O1. Alcanzar una base de 10000 usuarios activos en el primer semestre desde el lanzamiento.

  Se contabiliza como usuario activo toda cuenta que haya realizado un login, al menos, una vez durante la semana en la que se realiza la medición.

• O2. Conseguir al menos 200 usuarios taxistas al cabo de un semestre desde el lanzamiento.

  Se contabilizan como usuario taxista a todas las cuentas subscritas al servicio premium de la aplicación.

1.3 Identificar 4 tipos de stakeholders. Clasificarlos de algún modo: usuarios; clientes: dentro o fuera de la organización desarrolladora; usuarios directos o indirectos; usuarios favorecidos, desfavorecidos o ignorados…

Lista de stakeholders

• S1. Usuarios básicos: Población general que generalmente hacen uso del transporte público para sus desplazamientos. Utilizan la aplicación de manera gratuita.

• S2. Usuarios taxistas: Son todos los usuarios que poseen un servicio de taxi, que pagan una cuota de suscripción para poder ofrecer sus servicios y conseguir nuevos clientes a través de nuestra aplicación.

• S3. Desarrollador: Son los programadores, analistas o cualquier miembro del equipo técnico que participa en el desarrollo de la aplicación.

• S4. Hackers: Usuarios malintencionados, que intentan acceder a la plataforma para ejercer un uso fraudulento, como robar datos de usuarios.

Clasificación

• Interno o externo: Si están dentro o no de la organización o forman parte del equipo de desarrollo.

• Directo o indirecto: Si es usuario o no, en caso de ser usuario, será directo si se beneficia directamente de la aplicación o indirecto si se beneficia de sus resultados.

• Favorecido, desfavorecido, ignorado u otros:

  • Favorecidos, son a los que les ofrecemos funcionalidades que les aportan valor.

  • Desfavorecidos, son los usuarios a los que quiero impedir el uso de la aplicación.

  • Ignorados, usuarios irrelevantes.

  • Otros, los que no podemos clasificar en ninguna de las clases anteriores.

2. Definir requisitos de los usuarios (3 puntos, 1 punto cada apartado)

2.1 Seleccionar una clase de usuario e identificar para ella 4 casos de uso. Documentar cada uno de los casos de uso según la plantilla que se indica al final del enunciado. Representar además los casos de uso en un diagrama de casos de uso.

Casos de uso

Diagrama de casos de uso

2.2 Seleccionar un caso de uso de los elaborados en la sección anterior, y documentar sus escenarios empleando una secuencia de pasos numerada, o un diagrama de flujo (solo una de las dos opciones). No escojas un caso de uso trivial. que podria ser común a muchas aplicaciones, como el registro o el login. Que sea un caso de uso específico del dominio de aplicación considerado.

Caso de uso: UC04 Pedir taxi

• PRE04.1 El usuario ha iniciado sesión.

• PRE04.2 El usuario ha accedido a la sección de pedir taxi.

  ---

• UC04.1 El sistema localiza la ubicación del usuario.

• UC04.2 El sistema muestra los taxis disponibles ordenados por proximidad.

• UC04.3 El usuario selecciona el taxi que desea solicitar.

• UC04.4 El sistema le pide al usuario que introduzca el destino.

• UC04.5 El sistema muestra un resumen con los datos de la reserva.

• UC04.6 El usuario confirma que quiere pedir el taxi.

• UC04.7 El sistema comprueba los datos introducidos.

• UC04.8 El sistema realiza la reserva del taxi.

• UC04.9 El sistema mostrará un mensaje de confirmación de finalización.

2.3 Priorizar los 4 requisitos de usuario elaborados empleando la técnica de valor (ponderación del 0,5), coste (ponderación del 0,5) y riesgo (ponderación del 0,5).

3. Definir la especificación detallada del sistema (2 puntos, 1 punto cada apartado)

3.1 Para 2 casos de uso identificados, elaborar una especificación funcional detallada del sistema empleando la plantilla EARS.

Caso de uso: UC01 Crear taxi

• RF01: CUANDO el usuario taxista seleccione la opción de crear taxi, el sistema DEBERÁ mostrar un formulario con los siguientes datos:

  • Tipo de vehículo

  • Marca

  • Modelo

  • Numero de plazas

  • Aceptación de mascotas

  • Accesibilidad

• RF02: CUANDO el usuario taxista indica que quiere añadir el nuevo taxi, el sistema DEBERÁ validar que los campos introducidos son correctos:

  • Tipo de vehículo: cadena de texto alfanumérica con un máximo de 100 caracteres.

  • Marca: cadena de texto alfanumérica con un máximo de 30 caracteres.

  • Modelo: cadena de texto alfanumérica con un máximo de 30 caracteres.

  • Numero de plazas: número entero entre 1 y 8.

  • Aceptación de mascotas: valor booleano "SI" o "NO".

  • Accesibilidad: valor booleano "SI" o "NO".

• RF03: CUANDO el taxi es guardado en el sistema, el sistema DEBERÁ mostrar un mensaje de confirmación de finalización.

• RF04: SI durante la validación del formulario de RF01 se detecta algún dato que no cumple con las reglas definidas en RF02, ENTONCES el sistema DEBERÁ avisar al usuario del error, mostrando un mensaje y marcando en rojo aquellos datos que estén incorrectos.

• RNF01: SI al guardar los datos del taxi se produce un problema de comunicación con la base de datos, ENTONCES el sistema DEBERÁ reintentar el guardado dos veces más dejando un intervalo de tiempo de medio segundo entre cada reintento.

• RNF02: SI el sistema de reintentos falla, ENTONCES el sistema DEBERÁ mostrar un mensaje al usuario informado que "en estos momentos no se puede realizar esta acción".

• RNF03: SI el sistema de reintento falla 5 veces en menos de 5 minutos, ENTONCES el sistema DEBERÁ generar una alerta enviando un email de aviso al administrador del sistema.

Caso de uso: UC03 Pedir taxi

• RF05: CUANDO el usuario seleccione la opción "pedir taxi", el sistema DEBERÁ mostrar la lista de taxis disponibles ordenada por proximidad a la ubicación del usuario.

• RF06: CUANDO el usuario seleccione el taxi que desea solicitar, el sistema DEBERÁ notificar al taxista de que tiene una reserva en curso.

• RF07: CUANDO el usuario introduzca el destino, el sistema DEBERÁ mostrar un resumen con los datos de la reserva:

  • Datos de conductor

  • Vehículo

  • Tiempo estimado de recogida

  • Tiempo estimado de llegada al destino

  • Precio final del trayecto

• RF08: CUANDO el usuario confirme la reserva, el sistema DEBERÁ bloquear el taxi para evitar que otra persona reserve el mismo taxi.

3.2 Elaborar una matriz de trazabilidad entre casos de uso y los requisitos funcionales que has generado en el paso anterior.